Introducing Domain-Driven Design

開発者の仕事は「ソフトウェアを通じて問題を解決すること」であり、コーディングはソフトウェア開発の一側面に過ぎない。

そのため、優れた設計やコミュニケーションは、コーディング以上に重要である。

ソフトウェア開発をインプット（要件）とアウトプット（最終成果物）を持つパイプラインとして捉えると、garbage in, garbade out のルールが適用される。

インプットが悪ければ（要件が不明確だったり、設計が悪かったら）、コーディングしても良いアウトプットは生まれない。

DDD はすべてのソフトウェア開発に適しているわけではない。

たとえば、ゲーム開発やシステム・ソフトウェアなどは他のアプローチで構築できる。

しかし、エンジニア以外のチームと協力しなければならないビジネスソフトウェアやエンタープライズソフトウェアには特に有効である。

Domain Modeling Made Functional では、このようなソフトウェアに焦点を当てている。

共有されたモデルを作成するガイドライン